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© Scheduling policies with grouping for providing VCR control functions In a video server. 



© An integrated scheduling approach that provides 
VCR control functions to clients without always re- 
quiring a separate video stream for all clients. When 
a client invokes a resume, following a pause, the 
system uses a hierarchy of methods to handle the 
request. If an ongoing video stream is available such 
that the point at which the client is paused will be 
reached by that stream within a tolerable delay, the 
client is assigned to the ongoing stream. If no such 
stream is available, and the client request can not be 
served from a buffer, the system assigns the client 
to a reserve stream taken from a pool of reserved 
server capacity. If no reserved server capacity is 
available, the client is given priority for assignment 
to the next stream to become available. 
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I. Background of the Invention 
Field of the Invention 

The present invention relates to movie-on-de- 
mand systems of the type wherein multiple clients 
are serviced by video streams deliver from a cen- 
tral video server. Furthermore, the present inven- 
tion relates to the support of on-demand pause- 
resume in a central video server. 

Related Art 

Look-ahead Scheduling to Support Video-on-De- 
mand Applications 

The feature of pause-resume is one of the 
most common operations in VCR. Recently, it has 
become increasingly popular to develop multimedia 
servers to support video-on-demand (VOD) applica- 
tions. In a VOD environment, there are often hot 
videos which are requested by many viewers. The 
requirement that each viewer can independently 
pause the video at any instance and later resume 
the viewing has caused difficulties in batching of 
viewers on each showing. 

In one conventional approach to support on- 
demand pause-resume, one video stream is pro- 
vided for each viewer video request. For each 
multimedia server, there is a maximum number of 
video streams to the disks that can be supported. 
This upper limit will be referred to as N MAX . Thus, 
the above-described approach can only support 
Nmax viewers. 

In another conventional approach to the pause- 
resume problem, video streams are scheduled 
such that they become available at fairly close 
intervals. In response to receipt of a resume com- 
mand from a viewer (after having received a pause) 
the server assigns to the viewer one of the video 
streams which is scheduled to become available in 
the near future. One problem with such a system is 
that the viewer must wait until the next video 
stream becomes available before the movie is re- 
sumed. 



II. Summary Of The Invention 

In light of the above, it is and object of the 
invention to provide efficient support for the pause- 
resume requirement. 

An integrated scheduling approach that pro- 
vides VCR control functions to clients without al- 
ways requiring a separate video stream for all 
clients. When a client viewing a multicast stream (a 
common stream being shared by multiple viewers 
who have not paused) invokes a resume, following 
a pause, the system uses a hierarchy of methods 



to handle the request. If an ongoing video stream is 
available such that the point at which the client is 
paused will be reached by that stream within a 
tolerable delay, the client is assigned to the on- 

5 going stream. If no such stream is available, the 
system assigns the client to a reserve stream taken 
from a pool of reserved server capacity. If no 
reserved server capacity is available, the client is 
given priority for assignment to the next stream to 

10 become available. 

III. Brief Description of The Drawings 
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FIG. 1 is a block diagram of a video-on-demand 
system according to an embodiment of the 
present invention; 

FIG. 2 shows the format of a request record; 
FIG. 3 shows the structure of the stream table of 
FIG. 1; 

FIG. 4 is a flow chart of pause request handling 
by the client schedular of FIG. 1 ; 
FIG. 5 is a flow chart of resume request han- 
dling by the client schedular of FIG. 1; 
FIG. 6 is a flow chart of start request handling 
by the client schedular of FIG. 1 ; 
FIGs. 7 is a flow chart of the schedular's alloca- 
tion task; and, 

FIG. 8 is a flow chart of the normal priority 
allocation method of the allocation task. 

IV. Detailed Description of The Preferred Embodi- 
ments 



FIG. 1 is a block diagram of a video-on-de- 
35 mand system according to an embodiment of the 
present invention. In the following description, it is 
assumed that in a video-on-demand system clients 
10 make requests from a server 30 via a commu- 
nication network 20. The movies (videos) are 
40 stored on disks 50. The server and/or clients can 
have internal buffers 60, 70 for temporary storage 
of movies for handling short pause requests. The 
clients can make requests to start, stop, pause and 
resume a movie. The individual client requests are 
45 handled by a client scheduler 40. The client sched- 
uler attempts to conserve server resources by 
combining requests for the same movie that are 
close together in time while allowing each client to 
individually pause and resume, 
so A number of lists and tables are maintained by 
the client scheduler 40. Each client request to start 
or resume a movie results in a request record 110. 
The format of a request record is illustrated in FIG 
2. 

55 The request record 110 contains the identifier 
of the client (Client ID) 110a, the request priority 
(Priority) 110b, the identifier of the requested movie 
(Req. Movie ID) 110c, the block number of the 
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initial block requested (Initial Block) 1l0d and the 
time of the request (Request Time) 110e. The 
request priority 110b can be either high or normal. 
The request priority 110b is high if the request is 
for resuming a movie after a pause and normal if 
the request is for starting a movie. 

The initial block 110c is the first block if the 
request is to start a movie and may be some other 
block if the request is for resume. All high priority 
requests are linked in a list off a high priority queue 
head 100 while all normal priority requests are 
linked off a low priority queue 120. 

The client scheduler 40 also maintains a 
stream table 210 with an entry 212 for each active 
stream that is being played. The structure of the 
stream table is illustrated in FIG. 3. Each stream 
table entry 212 contains the stream identifier 
(Stream ID) 212a, the ID of the movie that is being 
shown (Current Movie ID) 212b and the block num- 
ber current block in the movie that is being dis- 
played (Current Block) 212c. The entry also con- 
tains a pointer (Request List) 21 2d to a linked list 
of client requests that are being satisfied by this 
stream. 

Two counters 220, 230 are used to keep track 
of the current spare capacity of the server. A 
contingency pool counter 220 keeps track of the 
number of contingency streams available. A normal 
pool capacity counter 230 keeps track of the num- 
ber of normal streams available. Contingency 
streams are used exclusively for handling resume 
requests while normal streams can be used to 
handle both resume and start requests. 

A flow chart of the handling of pause and stops 
requests by the client schedular is shown in FIG. 4. 
When a pause request or a stop request is made 
by a client, it is received by the client scheduler 40 
in step 310. In response, in step 320 the schedular 
40 deletes the request record for this client. Next, 
in step 330 the schedular checks to see if this 
stream is also being viewed by other clients. This 
is accomplished by finding the entry for this stream 
in the stream table 210 and examining the request 
list field 21 2d. If there are other clients viewing the 
stream, in step 340 the scheduler exits. 

If there are no other clients viewing the stream, 
the stream can be returned either to the contin- 
gency pool or the normal pool. Thus, in step 350 
the scheduler checks to see if there is sufficient 
capacity in the contingency pool. This is accom- 
plished by checking if the contingency pool capac- 
ity 220 is greater than the required capacity. The 
required capacity is a function of the number of 
paused clients, the number of multicast clients and 
the number of multicast streams. 

If there is insufficient capacity in the contin- 
gency pool 220, in step 360 the stream is returned 
to the contingency pool by incrementing the contin- 



gency pool capacity. Then, in step 370 the alloca- 
tion task for handling queued requests is rerun. 
This is done because new server capacity has 
become available by virtue of returning the stream 

5 to the contingency pool 220. 

If there is sufficient capacity in the contingency 
pool, in step 380 the stream is returned to the 
normal pool by incrementing the normal pool ca- 
pacity 230. Then, in step 390 the allocation task is 

10 rerun. 

A flow chart of resume request handling by the 
client schedular is shown in FIG. 5. When a re- 
sume request is made by a client, it is received by 
the client scheduler 40 in step 410. In response, in 

75 step 420 the scheduler 40 creates a request record 
for the request with the priority set to high and the 
initial block set to the requested block (in this case 
the block at which the movie is to be resumed). 
Next, in step 430 the scheduler checks to see 

20 if the request can be satisfied by an already exist- 
ing stream. This is accomplished by scanning the 
stream table 210 and comparing the block number 
in the stream entry with the initial block number in 
the request record. If the two block numbers are 

25 sufficiently close (for example less than a predefin- 
ed threshold t, such as 30 seconds), in step 440 
the scheduler adds the request record to the re- 
quest list for the stream and uses the stream to 
satisfy the request. Then in step 450 the schedular 

30 exits. If, in step 440, it is determined that the two 
block numbers are not sufficiently close, in step 
460 the scheduler determines if a contingency 
stream is available by checking the contingency 
pool capacity 220. 

35 if a contingency stream is available, in step 
470 the scheduler allocates a contingency stream 
for this request in by creating a stream entry (in 
the active stream table 210) for the new active 
stream, adding the request record to the request 

40 list 21 2d for this stream and decrementing the 
contingency pool capacity 220. The schedular then 
exits in step 480. 

If in step 460 the scheduler determines that no 
contingency stream is available, in step 490 the 

45 scheduler determines if a normal stream is avail- 
able by checking the normal pool capacity 230. If a 
normal stream is available, in step 500 the sched- 
ular allocates a normal stream for this request by 
creating a stream entry (in the active stream table 

50 210) for the new active stream, decrementing the 
normal pool capacity 230 and adding the request 
record to the request list 21 2d for the stream. If no 
normal stream is available, in step 510 the sched- 
uler queues the request record off the high priority 

55 queue and then exits in step 520. 

A flow chart of start request handling by the 
client schedular is shown in FIG. 6. When a start 
request is made by a client, it is received by the 
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client scheduler 40 in step 610. In response, in 
step 620 the scheduler creates a new request 
record 110 for the movie and queues this record 
off the normal priority queue 120. Then, the alloca- 
tion task is run in step 630. 5 

A flow chart of the schedular's allocation task is 
shown in FIGs. 7 and 8. The allocation task is 
invoked in step 710 at various points (described 
above) by the scheduler 40. When the allocation 
task is invoked, in step 720 scheduler first checks 10 
to see if there are any queued high priority re- 
quests by examining the high priority queue block 
100. If there are no high priority requests, in step 
730 the scheduler invokes the normal priority al- 
location task of FIG. 8. 75 

If there are high priority queued requests, in 
step 740 the scheduler determines if there are any 
contingency streams available. This is accom- 
plished by examining the contingency pool capac- 
ity 220. If a contingency stream is available, in step 20 
750 the scheduler satisfies the first high-priority 
request by allocating it a contingency stream. 

In order to allocate a contingency stream, the 
scheduler creates a stream entry in the stream 
table 210 for a new stream, decrements the contin- 25 
gency pool capacity 220 and adds the request 
record to the request list for the new stream. The 
schedular then repeats step 720. 

If there are no contingency streams available, 
in step 745 the scheduler determines if there are 30 
any normal streams available by checking the nor- 
mal pool capacity 230. If normal streams are avail- 
able, in step 760 the scheduler allocates a normal 
stream by creating a new entry in the active stream 
table 210, decrementing the normal pool capacity 35 
230 and adding the request record to the request 
list 21 2d for the new stream. The schedular then 
repeats step 720. 

If, in step 745, the schedular determines that 
no normal streams are available, the scheduler 40 
exits in step 770. 

The normal priority allocation task is shown in 
FIG. 8. The task is invoked in step 810 if there are 
no queued high priority requests. When the task is 
invoked, in block 820 the scheduler determines if 45 
there are any queued normal priority requests by 
examining the normal priority queue head 120. If 
there are no normal priority requests, the scheduler 
exits in step 830. 

If there are queued requests, in step 840 the 50 
scheduler examines the normal pool capacity 230 
to determine if there are any normal streams avail- 
able. If there are no available streams, the sched- 
uler exits in step 850. If there are available 
streams, the in step 860 scheduler executes the 55 
movie selection task. 

The movie selection task examines the time of 
request field of the request records to determine 



how long each request has been waiting. The mov- 
ie selection task uses these request waiting time to 
determine which movies (if any) to play. An exam- 
ple of a criteria which can be used by the movie 
selection task is to play all movies for which the 
earliest request has been waiting longer than a 
prespecified time (e.g. 3 minutes). In step 870, the 
scheduler checks to see if a movie has been 
selected for playing. If no movie was selected, the 
scheduler exits in step 880. If a movie was se- 
lected, all the requests for that movie can be satis- 
fied. The scheduler allocates a stream for that 
movie in step 890 by creating an new entry in the 
active stream table 210, chaining all the request 
records for that movie off the request list 21 2d for 
the stream and decrementing the normal pool ca- 
pacity 230. The schedular then returns to step 820 
to determine if there are any more queued normal 
priority requests. 

The present invention can also work in con- 
junction with buffering. In such an embodiment, a 
memory buffer is provided at the video server for 
storing short portions of a video being multicast for 
a paused client who was viewing the multicast 
stream. If the client pauses for a sufficiently small 
period of time such that the portion of the movie 
being transmitted while the client was paused can 
be stored in the buffer, the client is served from the 
buffer when he resumes. If the client pauses for a 
longer period of time than can be stored in the 
buffer, the resume request is handled in accor- 
dance with the above-described hierarchical meth- 
od. 

Now that the invention has been described by 
way of the preferred embodiment, various modi- 
fications and improvements will occur to those of 
skill in the art. Thus, it should be understood that 
the preferred embodiment has been provided as an 
example and not as a limitation. The scope of the 
invention is defined by the appended claims. 

Claims 

1. A method of supporting pause-resume for a 
video-on-demand service of a type which can 
accommodate multiple viewer sharing a com- 
mon data stream, comprising the steps of: 
receiving a performance request from one of 
the viewers for showing a particular video; 
concurrently transmitting the common data 
stream from a video server to reception equip- 
ment at the viewer's locations, transmission of 
the data stream causing the particular video to 
be performed on reception equipment at the 
viewer's locations; 

receiving at the video server, a pause request 
and a subsequent resume request from one of 
the viewers; 
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determining a point in the particular video at 
which the pause request was received by the 
video server; 

in response to the resume request, determin- 
ing whether another showing of the video, car- 5 
ried by a different data stream, is scheduled to 
reach the point at which the pause was re- 
ceived within a threshold time period; 
when it is determined that the another showing 
will reach the point at which the pause was 10 
received within the threshold time period, as- 
signing the viewer to the different data stream; 
when it is determined that the another showing 
will not reach the point at which the pause was 
received within the threshold time period, de- 15 
termining whether a reserved video stream is 
available, and if so assigning the viewer to a 
reserved data stream and transmitting the vid- 
eo, from the point at which the pause was 
received, on the reserved data stream; 20 
when it is determined that a reserved video 
stream is not available, waiting for an ongoing 
data stream to end and scheduling the user to 
have priority for assignment to the ongoing 
data stream. 25 

2. A method of supporting pause-resume for a 
video-on-demand service of a type which can 
accommodate multiple viewer sharing a com- 
mon data stream, comprising the steps of: 30 
receiving a performance request from one of 
the viewers for showing a particular video; 
concurrently transmitting the common data 
stream from a video server to reception equip- 
ment at the viewer's locations, transmission of 35 
the data stream causing the particular video to 
be performed on the reception equipment; 
receiving at the video server, a pause request 
and a subsequent resume request from one of 
the viewers; 40 
determining a point in the particular video at 
which the pause request was received by the 
video server; 

determining whether another showing of the 
video, carried by a different data stream, is 45 
scheduled to reach the point at which the 
pause was received within a threshold time 
period; 

when it is determined that the another showing 
will reach the point at which the pause was 50 
received within the threshold time period, as- 
signing the viewer to the different data stream. 

3. A method of supporting pause-resume for a 
video-on-demand service of a type which can 55 
accommodate multiple viewer sharing a com- 
mon data stream, comprising the steps of: 
receiving a performance request from one of 



the viewers for showing a particular video; 
concurrently transmitting the common data 
stream from a video server to reception equip- 
ment at the viewer's locations, transmission of 
the data stream causing the particular video to 
be performed on the reception equipment; 
receiving at the video server, a pause request 
and a subsequent resume request from one of 
the viewers; 

in response to the pause request, storing the 
data stream to an allocated portion of a mem- 
ory buffer; 

determining whether the client can be served 
from the buffer and still view the movie in 
continuity; 

when the movie can not be viewed from the 
buffer in continuity, in response to the resume 
request, determining whether another showing 
of the video, carried by a different data stream, 
is scheduled to reach the point at which the 
pause was received within a threshold time 
period; 

when it is determined that the another showing 
will reach the point at which the pause was 
received within the threshold time period, as- 
signing the viewer to the different data stream; 
when it is determined that the another showing 
will not reach the point at which the pause was 
received within the threshold time period, de- 
termining whether a reserved video stream is 
available, and if so assigning the viewer to a 
reserved data stream and transmitting the vid- 
eo, from the point at which the pause was 
received, on the reserved video stream; and, 
when it is determined that a reserved video 
stream is not available, waiting for an ongoing 
data stream to end and scheduling the user to 
have priority for assignment to the ongoing 
data stream. 

4. A method of supporting pause-resume for a 
video-on-demand system of a type which can 
accommodate multiple viewers, comprising the 
steps of: 

providing a contingency pool capacity com- 
prising a number of streams set aside for 
handling resume requests; 
providing a normal pool capacity comprising 
the remaining stream capacity of the video on 
demand system; 

receiving a performance request from one of 
the viewers for showing a particular video; 
concurrently transmitting a multicast stream 
from a video server to reception equipment at 
a plurality of the viewer's locations; 
receiving at the video server, a pause request 
and a subsequent resume request from one of 
the viewers; 
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determining a point in the particular video at 
which the pause request was received by the 
video server; 

determining when the pause request has been 
received from a viewer of a non-multicast 5 
stream; 

in response to a determination that the pause 
request was received from a viewer of the non- 
multicast stream, returning the stream capacity 
for the non-multicast stream to the contingency 10 
pool capacity when a number of the stream 
capacities in the contingency pool is below a 
threshold number and otherwise returning the 
stream capacity for the non-multicast stream to 
the normal pool capacity; 75 
in response to the resume request from a 
viewer of a multicast stream, determining 
whether another showing of the video, carried 
by a different data stream, is scheduled to 
reach the point at which the pause was re- 
ceived within a threshold time period; 
when it is determined that the another showing 
will reach the point at which the pause was 
received within the threshold time period, as- 
signing the viewer to the different data stream; 
when it is determined that the another showing 
will not reach the point at which the pause was 
received within the threshold time period, de- 
termining whether a reserved video stream is 
available from the contingency pool capacity, 
and if so assigning the viewer to the reserved 
data stream and transmitting the video, from 
the point at which the pause was received, on 
the reserved data stream; 
when it is determined that a reserved video 
stream is not available, waiting for an ongoing 
data stream to end and scheduling the user to 
have priority for assignment to the ongoing 
data stream. " 
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5. The method of claim 4 wherein the threshold 
number is computed as a function of the num- 
ber of paused streams, the number of mul- 
ticast streams and the number of multicast 
clients. 



40 



45 



50 



55 



6 



EP 0 673 159 A1 



FIG. \ 

VIDEO-ON-DEMAND ENVIRONMENT 
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FIG. 4 
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FIG. 5 



440 



1 



MERGE 



YES 



EXIT 



•450 



ALLOCATE 
CONTINGENCY 
STREAM 



YES 



470 



EXIT 



.480 



510 



RESUME 



410 



CREATE 
REQUEST RECORD 



420 



430 




YES 



NO 



500 



ALLOCATE 
NORMAL STREAM 



QUEUE REQUEST RECORD 
ON HIGH-PRIORITY QUEUE 



EXIT 



EXIT 



•520 



11 



EP 0 673 159 A1 



FIG. 6 
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FIG. 8 
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